LockBit Ransomware Group Augments Its Latest Variant, LockBit 3.0, With BlackMatter Capabilities
As part of its encryption process, LockBit 3.0 appends the extension HLJkNskOq (Figure 3) and changes the icons of encrypted files to that of the aforementioned .ico file.
Similarities to BlackMatter ransomware
Researchers have pointed out that portions of LockBit 3.0’s code seem to be borrowed from the BlackMatter ransomware, hence the nickname LockBit Black. Likewise, we found similarities between BlackMatter and the new LockBit variant during our debugging of the LockBit 3.0 sample. From our examination of the unpacked sample and an analysis provided by the researcher Chuong Dong, we discovered that LockBit 3.0 requires a pass parameter to decrypt its main routine (Figure 6). Other ransomware families like Egregor have been observed exhibiting this same behavior, where an argument is required to proceed with the routine. This makes the binary harder to reverse if the parameter is not available.
LockBit 3.0 performs API harvesting by hashing the API names of a DLL, and then comparing it to the list of the APIs that the ransomware needs (Figure 7). This routine is identical to that of BlackMatter (Figure 8), as the externally available script for renaming BlackMatter’s APIs also works for LockBit 3.0 (Figures 9 and 10).
Instead of directly calling the addresses of the harvested APIs, LockBit 3.0 implements a trampoline pointer (Figure 11) to go to an allocated heap that contains a disassembly code that will then jump to the API address of the NtTerminateProcess API (Figure 12). The code contained in the heap is randomly chosen from this set of codes:
- ROR by random number
- ROL by random number
- XOR to key
- ROR by random number, then XOR to key
- ROL by random number, then XOR to key
LockBit 3.0 and BlackMatter also implement the same antidebugging technique: Both set the thread information to ThreadHideFromDebugger (0x11) via the NtSetThreadInformation API (Figure 13) to cause any debuggers to crash if a breakpoint is placed on this thread.
Like BlackMatter, LockBit 3.0 employs threading when using an API instead of directly calling an API, which is likely an attempt to make it more difficult for researchers to analyze. The strings it uses are decrypted using a simple bitwise-XOR routine (Figure 14), a bitwise-XOR and NOT routine (Figure 15), or a decryption routine involving a linear congruential generator (LCG) algorithm to generate a pseudorandom key (Figure 16). This is also similar to how BlackMatter operates, except for the addition of the bitwise-XOR and NOT routine.
LockBit 3.0’s configurations (Table 1) are decrypted using the same XOR routine and keys obtained from an LCG pseudorandom number generator, and then decompressed using a compression library called APLib.
|
Configuration |
Description |
|
PUB_KEY[0x80] |
RSA public key |
|
VICT_ID[0x10] |
Victim ID (This is based on BlackMatter’s code, but is not used by LockBit 3.0.) |
|
AES_KEY[0x10] |
AES_KEY for the command-and-control (C&C) server (This is based on BlackMatter’s code, but is not used by LockBit 3.0.) |
|
FLAGS[0x18] |
Flags for specific routines |
|
OFFSET_ARRAY |
Array of the offset of Base64-encoded strings from this address (The length of the array is equal to the first value.) |
|
BASE64_STRING |
Array of Base64-encoded strings, which includes:
|
LockBit 3.0 also checks the victim machine’s UI language to avoid infecting machines with these languages:
- Arabic (Syria)
- Armenian (Armenia)
- Azerbaijani (Cyrillic Azerbaijan)
- Azerbaijani (Latin Azerbaijan)
- Belarusian (Belarus)
- Georgian (Georgia)
- Kazakh (Kazakhstan)
- Kyrgyz (Kyrgyzstan)
- Romanian (Moldova)
- Russian (Moldova)
- Russian (Russia)
- Tajik (Cyrillic Tajikistan)
- Turkmen (Turkmenistan)
- Tatar (Russia)
- Ukranian (Ukraine)
- Uzbek (Cyrillic Uzbekistan)
- Uzbek (Latin Uzbekistan)
LockBit 3.0 also retains these BlackMatter routines for privilege escalation:
- Uses UACMe’s method of bypassing user account control (UAC), which is to use the ICMLuaUtil COM interface under dllhost.exe
- Duplicates the Explorer.exe token for its own use
- Performs a 32-bit or 64-bit shellcode injection to elevate its token
The string that both LockBit 3.0 and BlackMatter use as the encrypted file name extension, ransom note name, and wallpaper and icon name is a Base64-encoded hash (Figure 17). However, a key difference between the two pieces of ransomware is that LockBit 3.0 opts to use an RSA public key embedded in its configuration and hash it with MD5, whereas BlackMatter uses a MachineGUID hashed using the same algorithm for APIs. This makes the string similar for all machines infected by the same sample, which is likely an attempt by LockBit’s operators to make it easier for them to identify which RSA private key pair is needed for an encrypted file.
Like BlackMatter, LockBit 3.0 also performs these routines:
- Attempts to log in using credentials from its configuration list to determine if the compromised system is a part of the domain admin that it will use for later routines
- Terminates and deletes processes and services from its configuration list, a routine similar to that of BlackMatter
- Wipes the recyle bin folder of every drive
- Checks a list of computer name hashes to avoid from its configuration list
- Connects to the C&C server from its configuration list if the flag is set
- Encrypts network shares and Exchange Mailbox if set in its configuration flag
- Obtains a list of files, folders, and extensions to be avoided from its configuration list
- Uses pointed files when encrypting .lnk files
- Prints the ransom note on any available printers and modifies the desktop wallpaper
- Uses the same encryption algorithm as BlackMatter
LockBit 3.0’s deletion of shadow copies (Figure 18) is clearly lifted from BlackMatter’s code, as this is performed using Windows Management Instrumentation (WMI) through COM objects, as opposed to LockBit 2.0’s use of vssadmin.exe.
This latest LockBit iteration performs some routines only if a specific argument is provided. LockBit 3.0 accepts only the arguments listed in Table 2, while BlackMatter accepts only the -safe, -wall, and -path arguments.
|
Argument |
Description |
|
-pass {value} |
Uses the first 32 characters of the value as a key to decrypt the main routine (This is required for the ransomware to execute properly.) |
|
-safe |
Reboots in SafeBoot |
|
-wall |
Only sets the ransomware wallpaper and prints the ransom note on printers |
|
-path {target} |
Specifically encrypts the target, which can be a file or folder |
|
-gspd |
Performs group policy modification for lateral movement |
|
-psex |
Performs lateral movement via admin shares |
|
-gdel |
Deletes group policy updates |
|
-del |
Deletes itself |
The new LockBit variant checks arguments using hashing and based on the code. It’s designed to perform only one routine from the arguments except for -pass, which needs to be performed before the other arguments can be checked. The routines to print the ransom note and change the victim machine’s wallpaper is also similar to BlackMatter’s routines if the -wall argument is provided. Like BlackMatter, LockBit 3.0 can also restart in safe mode and execute via the RunOnce registry, as long as the -safe argument is provided.
However, there is one key difference between their configuration flags: BlackMatter has only nine flags while LockBit 3.0 has 24, as detailed in Table 3.
|
Configuration flag |
Description |
|
ENCRYPT_LARGE_FILE_FLAG |
If set, a large file will be included in the encryption routine. |
|
RANDOM_FILE NAME_FLAG |
If set, encrypted files will be renamed to random file names. |
|
ATTEMPT_LOGON_FLAG |
If set, a login attempt will be made using credentials from LockBit 3.0’s configuration list, and the credentials will be saved if these have domain admin rights. |
|
EXCLUDE_HIDDEN_FLAG |
If set, hidden files will not be encrypted. |
|
CHECK_UI_LANGUAGE_FLAG |
If set, the victim machine’s UI language will be checked and the ransomware will terminate if the machine is from any of the avoided countries. |
|
MOUNT_VOL_ENC_EXCHANGE_SERVER_FLAG |
If set, all volumes for encryption will be mounted and available exchange servers will be encrypted. |
|
ENC_SHARED_FLAG |
If set, shared folders will be encrypted. |
|
TERMINATE_PROCESS_FLAG |
If set, processes from LockBit 3.0’s configuration list will be terminated. |
|
DELETE_SERVICE_FLAG |
If set, services from LockBit 3.0’s configuration list will be deleted. |
|
CREATE_MUTEX_FLAG |
If set, a check will be done to see whether mutex is already created and the ransomware will terminate if it is. |
|
PRINT_RANSOM_NOTE_FLAG |
If set, the ransom note will be printed on available printers. |
|
CHANGE_WALLPAPER_FLAG |
If set, the victim’s wallpaper will be changed. |
|
CHANGE_ICON_FLAG |
If set, the icons of encrypted files will be changed. |
|
CONNECT_TO_CNC_FLAG |
If set, communication will be done with a C&C server from LockBit 3.0’s configuration list. |
|
DELETE_SELF_FLAG |
If set, the ransomware will delete itself using a dropped .tmp file. |
|
DELETE_AV_SERVICE_FLAG |
If set, AV services matching the hashes will be terminated. |
|
CREATE_TEMP_MAX_DISKSPACE |
If set, another .tmp file (from the same .tmp file used in DELETE_SELF_FLAG flag) will be created on each drive with random contents and sizes based on DiskFreeSpace. |
|
HAS_ADMIN_CRED_FLAG |
If set, an attempt will be made to use admin credentials obtained from the ATTEMPT_LOGON_FLAG flag. |
|
RUN_AS_ADMIN_FLAG |
If set, commands will be executed as admin using credentials from the ATTEMPT_LOGON_FLAG flag. |
|
FORCE_GPUPDATE_VIA_POWERSHELL_FLAG |
If set, group policy updates will be forced on all active directories using a PowerShell command. |
|
DELETE_TEMP_FLAG |
If set, the same .tmp file used in the DELETE_SELF_FLAG flag will be deleted via MoveFileExW and the victim machine will be restarted. |
|
DISABLE_EVENTLOG_FLAG |
If set, EventLog will be disabled via registry and service. |
|
DELETE_GPO_FLAG |
If set and the -gspd parameter is used, the victim machine’s sleep time will be set to 1 minute before performing routines that will delete group policy updates. |
|
UNUSED_FLAG |
An extra flag that’s not used in the analyzed binary (or possibly an indicator of the end of flags). |
One notable behavior for this third LockBit version is its file deletion technique: Instead of using cmd.exe to execute a batch file or command that will perform the deletion, it drops and executes a .tmp file decrypted from the binary. It has, however, retained some of LockBit 2.0’s features, like the earlier version’s ability for lateral movement through a group policy update, as long as there is a -gspd parameter provided.
The executed .tmp file overwrites the contents of the ransomware binary and then renames the binary multiple times (Figure 19), with the new file names based on the length of the original file name. For example, a file named 1.exe, which has five characters (including the file name extension), is renamed as AAAAA, and then BBBBB, up to ZZZZZ. After renaming the file, LockBit 3.0 finally deletes it (Figure 20). This routine is probably the LockBit ransomware group’s attempt to avoid recovery by forensic tools and cover their tracks by completely removing any trace of the ransomware.
LockBit 3.0 on VirusTotal
A researcher recently spotted another LockBit 3.0 sample on VirusTotal (Figure 21), with 19 detections at the time of this writing. This specific sample is a PowerShell script containing two layers of obfuscated code (Figures 22 and 23). After deobfuscating the script (Figure 24), we found that LockBit 3.0 is capable of injecting a DLL into memory via reflective loading (Figure 25), using code that is identical to BlackMatter’s own PowerShell code (Figure 26).
This particular sample has a payload that is compressed and encrypted via Base64 (Figure 27). To access it, we modified the script to dump the payload instead of executing it (Figure 28). By dumping the payload, we were able to obtain LockBit 3.0’s main binary (Figure 29).
When it is executed, the script exhibits the same behavior as the previously discovered LockBit 3.0 sample. This specific sample appends 19MqZqZ0s to the file names of encrypted files (Figure 30).
The payload of this specific LockBit 3.0 sample checks for only three hashed arguments (Figure 31), while the previous LockBit 3.0 sample checks for eight. Its DLL payload is reflectively loaded, and the codes of its propagation routine via admin shares and group policy are designed for PE (Portable Executable) binaries, not for a PowerShell script, which might explain why some of the routines don’t work. Another possibility is that LockBit 3.0’s ransomware builder might have the option to disable certain routines. This LockBit 3.0 sample with the PowerShell script doesn’t need a pass “key” to run even if there is a check for the -pass argument, although the rest of its routines are the same as those in the abovementioned sample with a Win32 .exe file.
Locking out ransomware attacks
The LockBit ransomware gang led the ransomware-as-a-service (Raas) scene in the first quarter of 2022, with 220 self-reported successful RaaS and extortion attacks. One headline-making attack reportedly took place in January, during which LockBit operators claimed to have breached France’s Ministry of Justice. It would be no surprise if some of BlackMatter’s affiliates had joined the ranks of the LockBit group, considering LockBit’s recent rise in notoriety, which would explain the many similarities between the two pieces of ransomware.
With the release of this latest variant — and the launch of LockBit’s bug bounty program, which rewards its affiliates — we expect the LockBit ransomware group to be even more active in the coming days. We advise organizations and end users to be wary of this new variant, especially since the bug bounty program might help the operators in making their ransomware an even more formidable one. Best practices for mitigating the risk of a ransomware attack include:
- Following the 3-2-1 rule, which involves backing up files in three copies in two different formats, with one copy stored off-site. This is a precautionary measure to avoid data loss in case of a ransomware attack.
- Remaining vigilant against socially engineered emails to reduce the risk of a ransomware infection, as ransomware is commonly spread through malicious spam email attachments.
- Keeping applications and programs up to date. Regular patching ensures that software vulnerabilities that ransomware actors could exploit as entry points can be addressed in a timely fashion.
Organizations can benefit from a multilayered approach that can help guard possible entry points into a system (endpoint, email, web, and network). Trend Micro offers a suite of security solutions that can detect malicious components and suspicious behavior, and improve an enterprise’s security posture. Trend Micro Vision One™ provides multilayered protection and behavior detection, which helps block suspicious behavior early in a system before a ransomware infection can do irreversible damage. Trend Micro™ Deep Discovery™ Email Inspector uses custom sandboxing and advanced analysis techniques to block malicious emails, including phishing emails that are common entry points for ransomware. Additionally, Trend Micro Apex One™ offers automated threat detection and response to protect endpoints from more advanced concerns such as fileless threats and ransomware.
